Tricks of the Mac Game Programming Gurus/TricksOfTheMacGameProgrammingGurus.iso/Information/CSMP Digest/volume 1/csmp-v1-155.txt

Text File | 1994-12-08 | 53.7 KB | 1,185 lines | [TEXT/R*ch]

C.S.M.P. Digest             Mon, 03 Aug 92       Volume 1 : Issue 155

Today's Topics:

    Printers (was: Re: XWindows)
    sources
    PPCToolbox questions
    INITS; extentions ...
    A Simple BlockMove Question



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  The most recent issues
are available from sumex-aim.stanford.edu [36.44.0.6] in the directory
/info-mac/digest/csmp.  If you don't have ftp capability, the sumex archive
has a mail server; send a message with the text '$MACarch help' (no quotes)
to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (Gary Henderson)
Subject: Printers (was: Re: XWindows)
Organization: Lockheed Missiles and Space Co.
Date: Mon, 22 Jun 92 17:38:55 GMT

In article <[e-mail]> [e-mail]
(Lawrence D'Oliveiro, Waikato University) writes:

>In article <[e-mail]>,
>[e-mail] (Gary Henderson) writes:

>> I could fit all of the TrueType printers I've seen in a thimble.

>What about the several *hundred* different models of printer for which you
>can get Mac printer drivers? *All* of them work with TrueType fonts--including
>the PostScript ones.

We have a 90 PPM IBM proprietary printer.  It has a PostScript
interpreter that runs on a mainframe.  This no more makes the printer a
PostScript printer than the Mac drivers make those "the several
*hundred* different models of printer [sic]" TrueType printers.

Also, if a *subset* of PostScript ("... including the PostScript ones.")
can already do anything TrueType can do, why add another proprietary
type format?  A multivendor de-facto standard solution already exists.
Apple should stop trying to confuse the issues with their proprietary
sub-standard technology, and spend their efforts supporting standards
and adding value.

I should add that "printers I've seen" refers to those that I've seen in
operation.  Pictures in magazines don't count.  (I've seen *many*
printers).

- --
Gary J. Henderson
[e-mail]
#include <std/disclaimer.h>

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 24 Jun 92 05:42:19 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Gary Henderson) writes:
> In article <[e-mail]> [e-mail]
> (Lawrence D'Oliveiro, Waikato University) writes:
>
>>In article <[e-mail]>,
>>[e-mail] (Gary Henderson) writes:
>
>>> I could fit all of the TrueType printers I've seen in a thimble.
>
>>What about the several *hundred* different models of printer for which you
>>can get Mac printer drivers? *All* of them work with TrueType fonts--including
>>the PostScript ones.
>
> We have a 90 PPM IBM proprietary printer.  It has a PostScript
> interpreter that runs on a mainframe.  This no more makes the printer a
> PostScript printer than the Mac drivers make those "the several
> *hundred* different models of printer [sic]" TrueType printers.

As I recall, the Linotronic 100 (or was it the 300?) had a PostScript RIP
in a separate box from the actual imaging engine. Does this qualify as
a PostScript typesetter by your definition? Where do you draw the line?
As I recall, the Linotronics were the _only_ option for many years, for
people wanting typeset-quality PostScript output.

> Also, if a *subset* of PostScript ("... including the PostScript ones.")
> can already do anything TrueType can do, why add another proprietary
> type format?  A multivendor de-facto standard solution already exists.
> Apple should stop trying to confuse the issues with their proprietary
> sub-standard technology, and spend their efforts supporting standards
> and adding value.

The de-facto standard exists, but it's not good enough. It requires too
much hardware power to work properly (how many million Mac Classics has Apple
sold already? Can you imagine doing on-screen graphics with PostScript on
one of them?). It wasn't originally designed for interactive graphics (though
now you have Display PostScript, which is _another_ flavour of the "standard",
and the standard isn't so standard any more). There was no good open font
format--Type 1 was never intended as an open format, and Type 3 doesn't seem to
be a serious option.

Anyway, PostScript *can't* do everything TrueType/QuickDraw can do--and I never
said it could. There are QuickDraw drawing modes that work with TrueType
text on screen and on dumb printers, but don't translate well on "smart"
PostScript printers. Of course, it works the other way too, and therein
you have the basic problem of trying to simultaneously manage two imaging models
with quite different mindsets. Apple has a good solution for getting rid of
one of them, and I for one am keen to see how they go.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
To someone with a hammer and a screwdriver, every problem looks
like a nail with threads.

+++++++++++++++++++++++++++

From: [e-mail] (P. Hawthorne)
Date: 24 Jun 92 09:10:57 GMT
Organization: Reed College, Portland, Oregon

[It's alarming to see how little is known about the DTP environment in
this forum, given how much is known about mechanisms that drive it.]


  [e-mail] (Gary Henderson) writes:
. We have a 90 PPM IBM proprietary printer. It has a PostScript
. interpreter that runs on a mainframe. This no more makes the printer
. a PostScript printer than....

  Actually, that just makes the mainframe a PostScript RIP. It's
probably a hot one, but together with the printer, you have yet another
PostScript device. Note that the word 'device' is used rather than
printer. There's a good reason for that.
  There's a bakery at a nearby Safeway that images PostScript onto cakes
with frosting. PostScript drives slide recorders, imagesetters,
monitors, blade plotters, and sundry other arcanities too numerous to
mention. The range of PostScript devices is phenomenal.


  [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
. As I recall, the Linotronic 100 (or was it the 300?) had a PostScript . RIP
in a separate box from the actual imaging engine. Does this
. qualify as a PostScript typesetter by your definition?

  That's an oxymoron. If it groks PostScript, it is an imagesetter, not
a typesetter. Typesetters have joined molten lead type and quills as
archaic production methods, thanks to Adobe, lest we forget.
  In general, if the logic is a part of the imaging engine, it's a
controller. If it is independent, it's a RIP (Raster Image Processor).
Most, if not all, imagesetters have RIPs rather than controllers. That's
probably for the same reason that imagesetters are never bought, only
leased. Would you spend a quarter of a million bucks on a single box?


  [e-mail] (Gary Henderson) writes:
. Also, if a *subset* of PostScript ("... including the PostScript
. ones.") can already do anything TrueType can do, why add another
. proprietary type format?  A multivendor de-facto standard solution
. already exists. Apple should stop trying to confuse the issues with
. their proprietary sub-standard technology, and spend their efforts
. supporting standards and adding value.

  You said it, brother! You've just hit the nail on the head, and echoed
the feelings of the desktop publishing community at large. Apple has
done two big things wrong lately, or so it is said to the five
DTP sweatshops I hang out in.
  1. TrueType. The performance of the Mac printing system was bad
enough when TrueImage was announced. Since TrueType shipped,
printing has gotten flakier and much, much freakier.
  2. Finder 7. In a world where the PostScript and Illustrator are the
benchmarks of performance, Finder 7 is down there with FreeHand.
''It's like working underwater,'' is the running joke. (Incidentally,
the deep sea diver's motif is at odds with the rocket scientist motif
inspired by the wealth of Radius Rockets out there.)
  And I'm not just saying it because cubic curves suck eggs, either.
TrueType really does get in the way.


  [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
. The de-facto standard exists, but it's not good enough. It requires
. too much hardware power to work properly (how many million Mac
. Classics has Apple sold already? Can you imagine doing on-screen
. graphics with PostScript on one of them?).

  Come now. Adobe Illustrator, Aldus FreeHand, Deneba Canvas...
  The Classic has about as much power as the original LaserWriter.
You won't catch me trying to use a Classic for Adobe PhotoShop, but
the Classic can run some fine PostScript applications and get a lot of
work done.
  Maybe you're confusing licensing royalities with hardware power.
  The de facto standard exists, and works very, very well. Where it
begins to breakdown has either absolutely nothing to do with Apple such
as setting up screen angles for tritones, or everything to do with Apple
such as trying to separate printed-to-disk PostScript files.


  [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
.(though now you have Display PostScript, which is _another_ flavour
. of the "standard", and the standard isn't so standard any more).

  The standard remains. Display PostScript is essentially just an API
for PostScript Level II. L1 grandfathers into L2, and everything
works out fine in the end. Maybe we'd know more about Display PostScript
in the Mac community if Apple hadn't gone for Adobe's jugular, or if
Apple was willing to license Display PostScript.
  PostScript only gets faster, less buggy, and easier to cope with as
time goes on. Level II is really cool.

  TrueType, however, is a perpetual source of superstition and
weirdness. When your image, document, project, client, job, rent,
payroll, ulcer, whatever depends on getting the next graphic whipped
out, you don't want TrueType screwing up your seps, but it does.

  The moral of the story is that Apple doesn't even know what DTP is.
Apple should never have done TrueType.

  What did Apple have to prove with TrueType? That it ISN'T what it is
today because the LaserWriter was a PostScript device? That it could
survive without Adobe? That it will do anything Microsoft wants, even if
it means royally screwing over their customers to do it?

  To me, TrueType has proven just how lucky we are to have Adobe.

  An ex-production grub who prays in the
  general direction of Mountain View daily,
  Theus ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Gary Henderson)
Organization: Lockheed Missiles and Space Co.
Date: Wed, 24 Jun 92 14:51:03 GMT

In article <[e-mail]> [e-mail] (P. Hawthorne) writes:

>  [e-mail] (Gary Henderson) writes:
>. We have a 90 PPM IBM proprietary printer. It has a PostScript
>. interpreter that runs on a mainframe. This no more makes the printer
>. a PostScript printer than....

> [e-mail] (P. Hawthorne) replies:
>  Actually, that just makes the mainframe a PostScript RIP. It's
>probably a hot one, but together with the printer, you have yet another
>PostScript device. Note that the word 'device' is used rather than
>printer. There's a good reason for that.

Agreed.  I am aware of these distinctions and used the term PostScript
printer without defining it.  I shall loosely define a PostScript
*printer* to be a *printer* with a PostScript interpreter built into
(e.g. Laserwriter) or optionally installed in (e.g. HP LaserJet II) the
printer.  Printers that rely on RIP's running elsewhere (e.g. my IBM
example) would not qualify.  Without a definition like this, *any*
printer capable of dumping a bitmap is a potential [SUBSTITUTE IMAGING
MODEL HERE] printer - it just takes someone with enough patience to
write an [IMAGING MODEL] to printer-bitmap converter.

>  [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>. The de-facto standard exists, but it's not good enough. It requires
>. too much hardware power to work properly (how many million Mac
>. Classics has Apple sold already? Can you imagine doing on-screen
>. graphics with PostScript on one of them?).

> [e-mail] (P. Hawthorne) replies:
>  Come now. Adobe Illustrator, Aldus FreeHand, Deneba Canvas...
   [Let's not forget ATM, which gave us "true type" before TrueType.]
>  The Classic has about as much power as the original LaserWriter.

>  [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>.(though now you have Display PostScript, which is _another_ flavour
>. of the "standard", and the standard isn't so standard any more).

> [e-mail] (P. Hawthorne) replies:
>  The standard remains. Display PostScript is essentially just an API
>for PostScript Level II. L1 grandfathers into L2, and everything
>works out fine in the end. Maybe we'd know more about Display PostScript
>in the Mac community if Apple hadn't gone for Adobe's jugular, or if
>Apple was willing to license Display PostScript.
>  PostScript only gets faster, less buggy, and easier to cope with as
>time goes on. Level II is really cool.

And I quote, "You said it, brother!"

- --
Gary J. Henderson
[e-mail]
#include <std/disclaimer.h>

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 25 Jun 92 05:46:22 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (P. Hawthorne)
writes:

> [It's alarming to see how little is known about the DTP environment in
> this forum, given how much is known about mechanisms that drive it.]

I take your points about the DTP market. I'm even prepared to concede that
TrueType contributes nothing to the problem of trying to get decent-quality
output on high-end typesetters.

HOWEVER:

The DTP market isn't the whole Macintosh market. It's an important niche,
it's true (which is probably why Apple is rolling ATM into a future
Mac system), but I submit that the value of PostScript is questionable
outside this niche.

>   And I'm not just saying it because cubic curves suck eggs, either.

Interesting. PostScript is the one that uses cubic curves, not TrueType.

>   [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
> . The de-facto standard exists, but it's not good enough. It requires
> . too much hardware power to work properly (how many million Mac
> . Classics has Apple sold already? Can you imagine doing on-screen
> . graphics with PostScript on one of them?).
>
>   Come now. Adobe Illustrator, Aldus FreeHand, Deneba Canvas...

What is this list supposed to indicate? That these applications include
some kind of PostScript interpreter built-in? If you believe that...

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00

+++++++++++++++++++++++++++

From: [e-mail] (P. Hawthorne)
Date: 25 Jun 92 09:53:09 GMT
Organization: Reed College, Portland, Oregon


  [e-mail] (Lawrence D'Oliveiro) writes:
. The DTP market isn't the whole Macintosh market. It's an important niche,
. it's true (which is probably why Apple is rolling ATM into a future
. Mac system), but I submit that the value of PostScript is questionable
. outside this niche.

  You're right, of course. I've got tunnel vision in this regard.
  It is my feeling that the stability of PostScript within that niche has
been compromised by the emergence of TrueType, a product which I see only
dubious motivation for in the first place.
  I hope that's understandable, given the blinders I have on.


  Lawrence writes, after including my remarkably stupid statement about
  cubic curves:
. Interesting. PostScript is the one that uses cubic curves, not TrueType.

  It's my worst nightmare. I've really stuck my foot in my mouth now, in
front of God and everyone. I'm really very embarrassed, actually. I should
have known better than that, after pouring over that section of Foley and
van Dam so long trying to grasp the math involved.
  I should have said that having just one control point and two anchor
points (as opposed to having two control points and two anchor points)
seems as if it would suck eggs, but I've never tried it so I cannot be
absolutely certain. Then again, maybe it's better.
  What can I say? My confidence isn't what it used to be.


  Lawrence asks rhetorically:
. How many million Mac Classics has Apple sold already? Can you imagine
. doing on-screen graphics with PostScript on one of them?

  Theus cites:
. Adobe Illustrator, Aldus FreeHand, Deneba Canvas...

  Lawrence balks:
. What is this list supposed to indicate? That these applications include
. some kind of PostScript interpreter built-in? If you believe that...

  Now, before you try to sell me any beachfront property...
  Doing PostScript graphics on a QuickDraw screen is quite a sensational
feat, I admit. It's true the other way around as well, of course. (I'm
really quite amazed at the expressive power of Hertzfeld's regions.)
  I maintain, however, that these applications running on that machine can
generate adequate QuickDraw approximations of a tiny subset of PostScript.
Hence, Classics can do on-screen graphics with PostScript.


 "That'll be 15 Hail Mary's and a refresher on parametric cubic curves..."
  Theus ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Gary Henderson)
Date: 25 Jun 92 16:20:39 GMT
Organization: Lockheed Missiles and Space Co.

In article <[e-mail]>
[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:

>I take your points about the DTP market. I'm even prepared to concede that
>TrueType contributes nothing to the problem of trying to get decent-quality
>output on high-end typesetters.

>HOWEVER:

>The DTP market isn't the whole Macintosh market. It's an important niche,
>it's true (which is probably why Apple is rolling ATM into a future
>Mac system), but I submit that the value of PostScript is questionable
>outside this niche.

The engineering market isn't the whole Macintosh market, either - it's
probably about as far removed from DTP as you will get.  But when you
are designing the graphical output of a data analysis package, and
the output must

1) present all of the relevant information (just good engineering)
2) be of presentation/report quality
3) be portable among current and future platforms

the solution is obvious.  (Hint:  Its not TrueType).


D'Oliveiro writes:
>PostScript is the one that uses cubic curves, not TrueType.

PostScript uses cubic splines.  TrueType definitely uses a less
sophisticated curve algorithm.  I thought it was quadratic, but I
could be mistaken.  I'm certain that it takes more points to define a
character in TrueType than a similar character in PostScript.


D'Oliveiro writes:
>>> The de-facto standard exists, but it's not good enough. It requires
>>> too much hardware power to work properly (how many million Mac
>>> Classics has Apple sold already? Can you imagine doing on-screen
>>> graphics with PostScript on one of them?).

Reed replies:
>>   Come now. Adobe Illustrator, Aldus FreeHand, Deneba Canvas...

D'Oliveiro returns:
>What is this list supposed to indicate? That these applications include
>some kind of PostScript interpreter built-in? If you believe that...

If you believe that, you win the prize.  Actually, I can only speak
for Illustrator.  It has an interpreter that supports a very simple
subset of PostScript (and look at what that "simple subset" can do!).
In fact, Adobe publishes developer guidelines for the Illustrator
format, so those developers who wish to can limit their PostScript
output to this subset and have it viewable via Illustrator.  I
actually considered limiting my programs to this subset (so the Mac
could support electronic display of the output (like DECs, RS/6000s,
Suns...)) but decided it would be more practical to buy A/UX and port
Ghostscript.

- ------------------------

Computer vendors should support the standards, then add value.

- ------------------------

- --
Gary J. Henderson
[e-mail]
#include <std/disclaimer.h>

+++++++++++++++++++++++++++

From: [e-mail] (Gary Henderson)
Date: 25 Jun 92 16:33:01 GMT
Organization: Lockheed Missiles and Space Co.


First, please forgive my previous citing of Theus as "reed".  I
shoulda' let the computer type more and me type less.


Theus writes:
>  Lawrence writes, after including my ... statement about cubic curves:
>. Interesting. PostScript is the one that uses cubic curves, not TrueType.

I think that the popular press has referred to them cubics
(PostScript) and quadratics (TrueType).


> "That'll be 15 Hail Mary's and a refresher on parametric cubic curves..."
>  Theus ([e-mail])

I've heard of people calling these PostScript/QuickDraw things
"religious wars", but...


- ------------------------

Computer vendors should support the standards, then add value.

- ------------------------

- --
Gary J. Henderson
[e-mail]
#include <std/disclaimer.h>

+++++++++++++++++++++++++++

From: [e-mail] (JohnC)
Date: 25 Jun 92 15:50:54 GMT
Organization: The Royal Society for Putting Things on Top of Other Things

In article <[e-mail]> [e-mail] (P. Hawthorne) writes:
>  Now, before you try to sell me any beachfront property...
>  Doing PostScript graphics on a QuickDraw screen is quite a sensational
>feat, I admit. It's true the other way around as well, of course. (I'm
>really quite amazed at the expressive power of Hertzfeld's regions.)

You've got your Mac Elder Gods confused.  Bill Atkinson created the original
Quickdraw, and designed the region algorithms.  However, Andy Hertzfeld did
almost everything else. :-)


- --
John Cavallino                  |  EMail: [e-mail]
University of Chicago Hospitals |         [e-mail]
Office of Facilities Management | USMail: 5841 S. Maryland Ave, MC 0953
B0 f++ c+ g+ k s++ e+ h- pv     |         Chicago, IL  60637

+++++++++++++++++++++++++++

From: [e-mail] (Jamie R. McCarthy)
Date: 25 Jun 92 17:08:47 GMT
Organization: Kalamazoo College

[e-mail] (P. Hawthorne) writes:
>
>  Lawrence writes, after including my remarkably stupid statement about
>  cubic curves:
>. Interesting. PostScript is the one that uses cubic curves, not TrueType.
>
>  [Embarrassed confession deleted]  :-)
>  I should have said that having just one control point and two anchor
>points (as opposed to having two control points and two anchor points)
>seems as if it would suck eggs, but I've never tried it so I cannot be
>absolutely certain. Then again, maybe it's better.

Speaking totally objectively, as a font fanatic but non-curve-of-any-
kind-programmer, I can't tell the difference between a font rendered
with quadratic curves (TT) and a font rendered with cubic curves (ATM).
Yeah, maybe if you want a letter blown up six feet high, you'd need
twenty quadratic segments to get the same Absolutely Perfect Curve that
you could get with one cubic segment.  But I haven't used any 5000-point
letters lately.  And I've never noticed anything unacceptable about
well-designed TrueType fonts in regular (under-200-point) use.

On the other hand, TrueType 2.0 has got me really excited.  It sounds
like what Adobe's Multiple Master fonts should be.
- --
 Jamie McCarthy      Internet: [e-mail]      AppleLink: j.mccarthy
 Never piss off a computer.

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 26 Jun 92 18:51:11 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (P. Hawthorne) writes:

>   It's my worst nightmare. I've really stuck my foot in my mouth now, in
> front of God and everyone.

You're obviously human, so you're forgiven. :-)

>   I should have said that having just one control point and two anchor
> points (as opposed to having two control points and two anchor points)
> seems as if it would suck eggs, but I've never tried it so I cannot be
> absolutely certain. Then again, maybe it's better.

There was the beginnings of a discussion on this long ago when I was
reading comp.lang.postscript. The quadratic curves that TrueType uses are
faster to draw than PostScript's cubic Beziers, but you end up needing more
control points to define a curve. Someone claimed to have found that, when you
need to do complex linear transformations on the points (e g to create rotated
and skewed text), the time it takes to transform the extra points actually
outweighs the time saved in drawing the simpler curves.

My response was that this was an unusual case, and I suggested that for the
usual situation of only scaling transformations (possibly even allowing for
non-uniform scaling), as would be the case for most ordinary text, TrueType
should be faster overall. I never got any confirmation or refutation of my
claim, though, so I don't know for sure.

I've also heard opinions from one or two graphic artist types that the
cubic curves in Illustrator were easier to manipulate than the quadratic
"smoothed polygons" in MacDraw (this was in the early days, when Illustrator
had just come out, and FreeHand was just a rumour called "MasterPiece"...).

>   Lawrence asks rhetorically:
> . How many million Mac Classics has Apple sold already? Can you imagine
> . doing on-screen graphics with PostScript on one of them?
>
>   Theus cites:
> . Adobe Illustrator, Aldus FreeHand, Deneba Canvas...
>
>   Lawrence balks:
> . What is this list supposed to indicate? That these applications include
> . some kind of PostScript interpreter built-in? If you believe that...
>
>   Now, before you try to sell me any beachfront property...
>   Doing PostScript graphics on a QuickDraw screen is quite a sensational
> feat, I admit. It's true the other way around as well, of course. (I'm
> really quite amazed at the expressive power of Hertzfeld's regions.)
>   I maintain, however, that these applications running on that machine can
> generate adequate QuickDraw approximations of a tiny subset of PostScript.
> Hence, Classics can do on-screen graphics with PostScript.

All it proves is that you can run a graphics *model* which supports a lot
of the power of PostScript on these low-end machines (which should be good
news for QuickDraw GX, I imagine). I don't think that an actual full-fledged
Display PostScript implementation would be usable as the primary graphics
engine on such hardware--that was my point, at any rate. PostScript is
more than a set of graphics primitives: there's a lot of extra baggage
that you've got to look at *very* carefully when you're trying to get
things to work on a 68000 processor with an effective speed that's less
than 8MHz.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
Have a tree? No thanks, I'm trying to cut down...

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 26 Jun 92 18:59:43 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Jamie R. McCarthy) writes:

> On the other hand, TrueType 2.0 has got me really excited.  It sounds
> like what Adobe's Multiple Master fonts should be.

I thought about this when I first heard about Multiple Masters, and it seems
to me the programming "language" in TrueType 1.0 should already be sufficiently
powerful to do anything you can do with Multiple Masters. What you would
have to do is make copies of the font, and poke different values into the part
of the "sfnt" resource that specifies initial values for the "control value
table". The hinting instructions could be written to interpret those particular
values that you poke as style parameters, as with Multiple Masters.

OK, so it's a hack, but it's only a *little* hack...

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
I don't speak for my employer. This is meant to be taken entirely personally.

---------------------------

From: [e-mail] (Atau Tanaka)
Subject: sources
Date: 22 Jun 92 19:07:11 GMT
Organization: DSO, Stanford University

I quickly checked comp.sources.mac, and found no unread articles. I understand
that this newsgroup is one that's archived and available on ftp.uu.net. Now the
question is, where on that vast ftp site do the comp.sources.mac live?

thanks

- --
           Atau Tanaka
       Center for Computer Research in Music & Acoustics
       (CCRMA)

       [e-mail]


+++++++++++++++++++++++++++

From: [e-mail] (Peter N Lewis)
Organization: NCRPDA, Curtin University
Date: Wed, 24 Jun 1992 08:00:38 GMT

In article <[e-mail]>, [e-mail] (Atau Tanaka) writes:
>
> I quickly checked comp.sources.mac, and found no unread articles. I understand
> that this newsgroup is one that's archived and available on ftp.uu.net. Now the
> question is, where on that vast ftp site do the comp.sources.mac live?

Give up now, and look for comp.binaries.mac archives.  The moderator of
comp.sources.mac is of the opinion (quite probably correctly) that only
human readable files may be posted to c.s.m.  Since no one is going to
take the time and effort required to convert all their project and resource
files into say rez format, and then join them all together in some sort of
mutated shar format (and even if they did its unlikely anyone on a mac
would ever get it back to a compilable state), nothing ever comes out of
comp.sources.mac.  Instead people post source files in the standard mac
format (.sit.hqx or .cpt.hqx) and so the moderator sends them to
comp.binaries.mac instead.  See the associated flame war in comp.sys.mac.misc
and the discussion of human-readable source formats in
comp.sys.mac.programmer.

Alternatively you could try ftping to sumex-aim.stanford.edu and looking
thru the /info-mac/source directory.

Have fun,
   Peter.

______________________________________________________________________
Peter N Lewis, NCRPDA, Curtin University      [e-mail]
GPO Box U1987, Perth WA 6001, AUSTRALIA            FAX: [phone]



---------------------------

From: [e-mail] (Dave Slotter)
Subject: PPCToolbox questions
Date: 22 Jun 92 20:54:01 GMT
Organization: DUsers

I am trying to use the IPCListPorts function to retrieve a list of ports, but
am having trouble setting up the LocationNameRec in c.  With different variants
of code that set up the npbEntity, I can get any of the three following errors
returned:

- -902 (nameTypeErr) "Invalid or inappropriate locationKindSelector in location
                    name"

- -915 (noResponseErr) "Unable to contact application"

- -931 (badLocNameErr) "Location name is invalid"

Does anyone have some sample code that sets up the IPCListPortsPBPtr?  I sure
could use some code or assistance in setting up the nbpEntity data structure.
Please send email to [e-mail] or a followup to this newsgroup.

Thank you for your time.

- -Dave Slotter
- --
[e-mail] (preferred)       | VP, The DUsers (World's first MUG)
[e-mail]                    | James Creese Student Union Complex
[e-mail]  | 3210 Chestnut Street
215-895-2573 voicemail 215-895-2579 BBS   | Philadelphia, PA  19104-3412, USA

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik (Hacker))
Date: 1 Jul 92 01:41:06 GMT
Organization: Apple

In article <[e-mail]>, [e-mail]
(Dave Slotter) wrote:
> Does anyone have some sample code that sets up the IPCListPortsPBPtr?  I sure
> could use some code or assistance in setting up the nbpEntity data structure.
> Please send email to [e-mail] or a followup to this newsgroup.

The Kibitz sources (ftp.apple.com) should have source code for setting
up IPCListPorts.

Kent Sandvik/DTS

---------------------------

From: [e-mail]
Subject: INITS; extentions ...
Date: 23 Jun 92 14:09:38 GMT
Organization: K.U.Leuven - Academic Computing Center

I'm looking for some source code as an example for
writing inits/extentions on the Mac. Any info on the
subject is welcome (no MacApp stuff please).

I've asked this before with very little response. Come on!
All you guys who are writing inits must have some code they
can make available to the public. I would like to see some
source (preferably with a project and rsrc file attatched)
which produces a working init which demonstrates the most
common stuff you have to do when writing an init.

It doesn't have to be your newest, all-singing and all dancing
shareware init, but some source some older (obsolete) init will do


(send binaries to [e-mail] !!!!!!!!!!!!!!!)


Hoping for enormous response

Karl Pottie

+++++++++++++++++++++++++++

From: [e-mail] (Aaron Wohl)
Date: 29 Jun 92 12:50:12 GMT
Organization: Special Projects, Carnegie Mellon, Pittsburgh, PA

Sources for an init, cdev and device driver are available from host
akutakak.andrew.cmu.edu [128.2.35.1] in the file
/aw0g/mailcheckx.sit.hqx.  The init/cdev/driver work together to check
your unix mail via udp. Mailcheck reports when there is new mail with a
notifcation dialog, blinking apple, or playing a sound.

There is some other stuff in /aw0g/mac_driver_toolkit1.0.sit.hqx for
writing dynamicly installed drivers.

I am working some replacing the serial drivers (.AIn/.AOut) and driving
the scc hardware directly to do syncronous HDLC, but it isn't finished
yet.  A test version of that executable is in /aw0g/softkiss.1.1t.sit.hqx

There is also a device driver to monitor appletalk packets and print
them out.  But the code is really bad... in /aw0g/seet.sit.hqx
Aaron

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik (Hacker))
Date: 29 Jun 92 22:13:26 GMT
Organization: Apple

In article <[e-mail]>,
[e-mail] wrote:
> I'm looking for some source code as an example for
> writing inits/extentions on the Mac. Any info on the
> subject is welcome (no MacApp stuff please).
>
> I've asked this before with very little response. Come on!
> All you guys who are writing inits must have some code they
> can make available to the public. I would like to see some
> source (preferably with a project and rsrc file attatched)
> which produces a working init which demonstrates the most
> common stuff you have to do when writing an init.
>
> It doesn't have to be your newest, all-singing and all dancing
> shareware init, but some source some older (obsolete) init will do

I have a nice template that one of our DTS engineers wrote some
time ago. Have to ask him if it's OK to publish it, would be good
as a starting point for patching and INIT writing.

Also, at the latest MacHack Allan Foster and Scott Boyd presented
a really nice template for patching, in MPW asm code. It will
appear on the MacHack CD, and eventually they will publish it
elsewhere as well (Allan, Scott?).

Finally, I also heard that MacTutor will have a future article
with C code for init writing and patching.

Cheers,
Kent
PS: MacApp for patching :-)))).

---------------------------

From: [e-mail] (Bob Noone)
Subject: A Simple BlockMove Question
Date: 23 Jun 92 14:12:15 GMT
Organization: Penn Med

Parden a simple question from a rather naive Pascal programmer...

Does the toolbox BlockMove routine *copy* the bytes to the new location
without altering the source?  I'm worried something is happening to a
pixmap image buffer I have, after I use it as a source in BlockMove.  I
would like to avoid using copybits for this.

- - Bob

+++++++++++++++++++++++++++

From:  ()
Date: Wed, 24 Jun 1992 16:21:52 GMT
Organization: Apple Computer Inc.

In article <[e-mail].>, [e-mail] (Bob Noone) writes:
>
> Parden a simple question from a rather naive Pascal programmer...
>
> Does the toolbox BlockMove routine *copy* the bytes to the new location
> without altering the source?  I'm worried something is happening to a
> pixmap image buffer I have, after I use it as a source in BlockMove.  I
> would like to avoid using copybits for this.
>

  BlockMove doesn't alter the source.

  On a somewhat tangential note, it's actually faster to have a tight
byte copying loop inline than it is to call BlockMove for small amounts
of data.  If I remember correctly, the crossover point is around 40'ish
bytes.  It's a little higher on the Quadras because BlockMove flushes
the cache for moves of larger than 12 bytes (it's assuming that you're
moving code).

  -- Dean Yu
     Blue Meanie, Negative Ethnic Role Model, etc.
     Apple Computer, Inc.


+++++++++++++++++++++++++++

From: [e-mail] (P. Hawthorne)
Date: 25 Jun 92 09:03:00 GMT
Organization: Reed College, Portland, Oregon


  Dean Yu writes:
. On a somewhat tangential note, it's actually faster to have a tight byte
. copying loop inline than it is to call BlockMove for small amounts of
. data. If I remember correctly, the crossover point is around 40'ish bytes.

  Ah, the crossover point! I found what you did, but figured I would try to
push that point as far up as I possibly could. I eventually wrote a general
purpose mover that outperforms BlockMove for moves of under 4K on my SE/30.
It eats huge overlapping moves for breakfast, uses the best caching loop
for a given move size, and resorts to calling BlockMove for moves over 4K.

  I give a disassembly of the routine below. I'd give asm source, but, er,
there never was any. I did this by hand in the ResEdit hex editor, all 197
instructions and sundry special cases of it. I'd do it a lot differently
now... If you take a look at this, I'd be ecastatic to get feedback.  Code
resource and Pascal unit available upon request.

  Cache warps performance in subtle ways one might never suspect if it
weren't for a couple kilos of Danessi Gold espresso, a Brasilia 2-group, an
acute case of obsession, and a solid week when my girlfriend was away.

  I thought I was being fairly clever seeing as how I was boggled by the
6809E and UART I had as a kid, much less daunting than the 68000 series.
(Anyone remember the FCC instruction?)

  This, the most general of the routines I came up with, basically works by
shifting off the byte count by one and moving bytes in successive powers of
two, a couple of times until the powers of two get big and we get to an all
out loop. The best size for that loop was what the cache made mysterious.
Eventually, I had IT decide on which size of loop to use, and it works.

  All out loops look like:

SUBQ.L     #$1,D0 // to cope with DBF's reliance on negative numbers
@1 // here are however many MOVE.Ls (2^x)
DBF        D0,@1
SUBI.L     #$10000,D0 // to cope with DBcc's 16-bit origins
BGT.S      @1 // not _even_ done yet!

  Theus ([e-mail])


procedure CopyBlock (src, dst: univ Ptr; count: Longint);
+0000  00007E  LINK       A6,#$0000                        | 4E56 0000
+0008  000086  MOVEA.L    $000C(A6),A1                     | 226E 000C
+000C  00008A  MOVEA.L    $0010(A6),A0                     | 206E 0010
+0010  00008E  MOVE.L     $0008(A6),D0                     | 202E 0008
+0014  000092  MOVE.L     A0,D1                            | 2208
+0016  000094  ADD.L      D0,D1                            | D280
+0018  000096  CMP.L      A1,D1                            | B289
+001A  000098  SLT        D1                               | 5DC1
+001C  00009A  CMPA.L     A0,A1                            | B3C8
+001E  00009C  SLT        D2                               | 5DC2
+0020  00009E  OR.B       D2,D1                            | 8202
+0022  0000A0  BEQ        COPYBLOC+$00FA      ; 00000178   | 6700 00D6
+0026  0000A4  CMPI.L     #$000000C4,D0                    | 0C80 0000 00C4
+002C  0000AA  BGT.S      COPYBLOC+$0068      ; 000000E6   | 6E3A
This is where it gets interesting.
+002E  0000AC  LSR.L      #$1,D0                           | E288
+0030  0000AE  BCC.S      COPYBLOC+$0036      ; 000000B4   | 6404
+0032  0000B0  MOVE.B     (A0)+,(A1)+                      | 12D8
+0034  0000B2  TST.L      D0                               | 4A80
+0036  0000B4  BEQ        COPYBLOC+$01D2      ; 00000250   | 6700 019A
+003A  0000B8  LSR.L      #$1,D0                           | E288
+003C  0000BA  BCC.S      COPYBLOC+$0046      ; 000000C4   | 6408
+003E  0000BC  MOVE.W     (A0)+,(A1)+                      | 32D8
+0040  0000BE  TST.L      D0                               | 4A80
+0042  0000C0  BEQ        COPYBLOC+$01D2      ; 00000250   | 6700 018E
+0046  0000C4  LSR.L      #$1,D0                           | E288
+0048  0000C6  BCC.S      COPYBLOC+$0052      ; 000000D0   | 6408
+004A  0000C8  MOVE.L     (A0)+,(A1)+                      | 22D8
+004C  0000CA  TST.L      D0                               | 4A80
+004E  0000CC  BEQ        COPYBLOC+$01D2      ; 00000250   | 6700 0182
+0052  0000D0  SUBQ.L     #$1,D0                           | 5380
+0054  0000D2  MOVE.L     (A0)+,(A1)+                      | 22D8
+0056  0000D4  MOVE.L     (A0)+,(A1)+                      | 22D8
+0058  0000D6  DBF        D0,COPYBLOC+$0054   ; 000000D2   | 51C8 FFFA
+005C  0000DA  SUBI.L     #$00010000,D0                    | 0480 0001 0000
+0062  0000E0  BGT.S      COPYBLOC+$0054      ; 000000D2   | 6EF0
+0064  0000E2  BRA        COPYBLOC+$01D2      ; 00000250   | 6000 016C
+0068  0000E6  CMPI.L     #$00000D00,D0                    | 0C80 0000 0D00
+006E  0000EC  BGT        COPYBLOC+$00F4      ; 00000172   | 6E00 0084
+0072  0000F0  LSR.L      #$1,D0                           | E288
+0074  0000F2  BCC.S      COPYBLOC+$007C      ; 000000FA   | 6406
+0076  0000F4  MOVE.B     (A0)+,(A1)+                      | 12D8
+0078  0000F6  TST.L      D0                               | 4A80
+007A  0000F8  BEQ.S      COPYBLOC+$00F6      ; 00000174   | 677A
+007C  0000FA  LSR.L      #$1,D0                           | E288
+007E  0000FC  BCC.S      COPYBLOC+$0086      ; 00000104   | 6406
+0080  0000FE  MOVE.W     (A0)+,(A1)+                      | 32D8
+0082  000100  TST.L      D0                               | 4A80
+0084  000102  BEQ.S      COPYBLOC+$00F6      ; 00000174   | 6770
+0086  000104  LSR.L      #$1,D0                           | E288
+0088  000106  BCC.S      COPYBLOC+$0090      ; 0000010E   | 6406
+008A  000108  MOVE.L     (A0)+,(A1)+                      | 22D8
+008C  00010A  TST.L      D0                               | 4A80
+008E  00010C  BEQ.S      COPYBLOC+$00F6      ; 00000174   | 6766
+0090  00010E  LSR.L      #$1,D0                           | E288
+0092  000110  BCC.S      COPYBLOC+$009C      ; 0000011A   | 6408
+0094  000112  MOVE.L     (A0)+,(A1)+                      | 22D8
+0096  000114  MOVE.L     (A0)+,(A1)+                      | 22D8
+0098  000116  TST.L      D0                               | 4A80
+009A  000118  BEQ.S      COPYBLOC+$00F6      ; 00000174   | 675A
+009C  00011A  LSR.L      #$1,D0                           | E288
+009E  00011C  BCC.S      COPYBLOC+$00AC      ; 0000012A   | 640C
+00A0  00011E  MOVE.L     (A0)+,(A1)+                      | 22D8
+00A2  000120  MOVE.L     (A0)+,(A1)+                      | 22D8
+00A4  000122  MOVE.L     (A0)+,(A1)+                      | 22D8
+00A6  000124  MOVE.L     (A0)+,(A1)+                      | 22D8
+00A8  000126  TST.L      D0                               | 4A80
+00AA  000128  BEQ.S      COPYBLOC+$00F6      ; 00000174   | 674A
+00AC  00012A  LSR.L      #$1,D0                           | E288
+00AE  00012C  BCC.S      COPYBLOC+$00C4      ; 00000142   | 6414
+00B0  00012E  MOVE.L     (A0)+,(A1)+                      | 22D8
+00B2  000130  MOVE.L     (A0)+,(A1)+                      | 22D8
+00B4  000132  MOVE.L     (A0)+,(A1)+                      | 22D8
+00B6  000134  MOVE.L     (A0)+,(A1)+                      | 22D8
+00B8  000136  MOVE.L     (A0)+,(A1)+                      | 22D8
+00BA  000138  MOVE.L     (A0)+,(A1)+                      | 22D8
+00BC  00013A  MOVE.L     (A0)+,(A1)+                      | 22D8
+00BE  00013C  MOVE.L     (A0)+,(A1)+                      | 22D8
+00C0  00013E  TST.L      D0                               | 4A80
+00C2  000140  BEQ.S      COPYBLOC+$00F6      ; 00000174   | 6732
+00C4  000142  SUBQ.L     #$1,D0                           | 5380
+00C6  000144  MOVE.L     (A0)+,(A1)+                      | 22D8
+00C8  000146  MOVE.L     (A0)+,(A1)+                      | 22D8
+00CA  000148  MOVE.L     (A0)+,(A1)+                      | 22D8
+00CC  00014A  MOVE.L     (A0)+,(A1)+                      | 22D8
+00CE  00014C  MOVE.L     (A0)+,(A1)+                      | 22D8
+00D0  00014E  MOVE.L     (A0)+,(A1)+                      | 22D8
+00D2  000150  MOVE.L     (A0)+,(A1)+                      | 22D8
+00D4  000152  MOVE.L     (A0)+,(A1)+                      | 22D8
+00D6  000154  MOVE.L     (A0)+,(A1)+                      | 22D8
+00D8  000156  MOVE.L     (A0)+,(A1)+                      | 22D8
+00DA  000158  MOVE.L     (A0)+,(A1)+                      | 22D8
+00DC  00015A  MOVE.L     (A0)+,(A1)+                      | 22D8
+00DE  00015C  MOVE.L     (A0)+,(A1)+                      | 22D8
+00E0  00015E  MOVE.L     (A0)+,(A1)+                      | 22D8
+00E2  000160  MOVE.L     (A0)+,(A1)+                      | 22D8
+00E4  000162  MOVE.L     (A0)+,(A1)+                      | 22D8
+00E6  000164  DBF        D0,COPYBLOC+$00C6   ; 00000144   | 51C8 FFDE
+00EA  000168  SUBI.L     #$00010000,D0                    | 0480 0001 0000
+00F0  00016E  BGT.S      COPYBLOC+$00C6      ; 00000144   | 6ED4
+00F2  000170  BRA.S      COPYBLOC+$00F6      ; 00000174   | 6002
+00F4  000172  _BlockMove                     ; A02E       | A02E
+00F6  000174  BRA        COPYBLOC+$01D2      ; 00000250   | 6000 00DA
+00FA  000178  CMPI.L     #$000000C4,D0                    | 0C80 0000 00C4
+0100  00017E  BGT.S      COPYBLOC+$0140      ; 000001BE   | 6E3E
+0102  000180  ADDA.L     D0,A0                            | D1C0
+0104  000182  ADDA.L     D0,A1                            | D3C0
+0106  000184  LSR.L      #$1,D0                           | E288
+0108  000186  BCC.S      COPYBLOC+$010E      ; 0000018C   | 6404
+010A  000188  MOVE.B     -(A0),-(A1)                      | 1320
+010C  00018A  TST.L      D0                               | 4A80
+010E  00018C  BEQ        COPYBLOC+$01D2      ; 00000250   | 6700 00C2
+0112  000190  LSR.L      #$1,D0                           | E288
+0114  000192  BCC.S      COPYBLOC+$011E      ; 0000019C   | 6408
+0116  000194  MOVE.W     -(A0),-(A1)                      | 3320
+0118  000196  TST.L      D0                               | 4A80
+011A  000198  BEQ        COPYBLOC+$01D2      ; 00000250   | 6700 00B6
+011E  00019C  LSR.L      #$1,D0                           | E288
+0120  00019E  BCC.S      COPYBLOC+$012A      ; 000001A8   | 6408
+0122  0001A0  MOVE.L     -(A0),-(A1)                      | 2320
+0124  0001A2  TST.L      D0                               | 4A80
+0126  0001A4  BEQ        COPYBLOC+$01D2      ; 00000250   | 6700 00AA
+012A  0001A8  SUBQ.L     #$1,D0                           | 5380
+012C  0001AA  MOVE.L     -(A0),-(A1)                      | 2320
+012E  0001AC  MOVE.L     -(A0),-(A1)                      | 2320
+0130  0001AE  DBF        D0,COPYBLOC+$012C   ; 000001AA   | 51C8 FFFA
+0134  0001B2  SUBI.L     #$00010000,D0                    | 0480 0001 0000
+013A  0001B8  BGT.S      COPYBLOC+$012C      ; 000001AA   | 6EF0
+013C  0001BA  BRA        COPYBLOC+$01D2      ; 00000250   | 6000 0094
+0140  0001BE  CMPI.L     #$00000D00,D0                    | 0C80 0000 0D00
+0146  0001C4  BGT        COPYBLOC+$01D0      ; 0000024E   | 6E00 0088
+014A  0001C8  ADDA.L     D0,A0                            | D1C0
+014C  0001CA  ADDA.L     D0,A1                            | D3C0
+014E  0001CC  LSR.L      #$1,D0                           | E288
+0150  0001CE  BCC.S      COPYBLOC+$0158      ; 000001D6   | 6406
+0152  0001D0  MOVE.B     -(A0),-(A1)                      | 1320
+0154  0001D2  TST.L      D0                               | 4A80
+0156  0001D4  BEQ.S      COPYBLOC+$01D2      ; 00000250   | 677A
+0158  0001D6  LSR.L      #$1,D0                           | E288
+015A  0001D8  BCC.S      COPYBLOC+$0162      ; 000001E0   | 6406
+015C  0001DA  MOVE.W     -(A0),-(A1)                      | 3320
+015E  0001DC  TST.L      D0                               | 4A80
+0160  0001DE  BEQ.S      COPYBLOC+$01D2      ; 00000250   | 6770
+0162  0001E0  LSR.L      #$1,D0                           | E288
+0164  0001E2  BCC.S      COPYBLOC+$016C      ; 000001EA   | 6406
+0166  0001E4  MOVE.L     -(A0),-(A1)                      | 2320
+0168  0001E6  TST.L      D0                               | 4A80
+016A  0001E8  BEQ.S      COPYBLOC+$01D2      ; 00000250   | 6766
+016C  0001EA  LSR.L      #$1,D0                           | E288
+016E  0001EC  BCC.S      COPYBLOC+$0178      ; 000001F6   | 6408
+0170  0001EE  MOVE.L     -(A0),-(A1)                      | 2320
+0172  0001F0  MOVE.L     -(A0),-(A1)                      | 2320
+0174  0001F2  TST.L      D0                               | 4A80
+0176  0001F4  BEQ.S      COPYBLOC+$01D2      ; 00000250   | 675A
+0178  0001F6  LSR.L      #$1,D0                           | E288
+017A  0001F8  BCC.S      COPYBLOC+$0188      ; 00000206   | 640C
+017C  0001FA  MOVE.L     -(A0),-(A1)                      | 2320
+017E  0001FC  MOVE.L     -(A0),-(A1)                      | 2320
+0180  0001FE  MOVE.L     -(A0),-(A1)                      | 2320
+0182  000200  MOVE.L     -(A0),-(A1)                      | 2320
+0184  000202  TST.L      D0                               | 4A80
+0186  000204  BEQ.S      COPYBLOC+$01D2      ; 00000250   | 674A
+0188  000206  LSR.L      #$1,D0                           | E288
+018A  000208  BCC.S      COPYBLOC+$01A0      ; 0000021E   | 6414
+018C  00020A  MOVE.L     -(A0),-(A1)                      | 2320
+018E  00020C  MOVE.L     -(A0),-(A1)                      | 2320
+0190  00020E  MOVE.L     -(A0),-(A1)                      | 2320
+0192  000210  MOVE.L     -(A0),-(A1)                      | 2320
+0194  000212  MOVE.L     -(A0),-(A1)                      | 2320
+0196  000214  MOVE.L     -(A0),-(A1)                      | 2320
+0198  000216  MOVE.L     -(A0),-(A1)                      | 2320
+019A  000218  MOVE.L     -(A0),-(A1)                      | 2320
+019C  00021A  TST.L      D0                               | 4A80
+019E  00021C  BEQ.S      COPYBLOC+$01D2      ; 00000250   | 6732
+01A0  00021E  SUBQ.L     #$1,D0                           | 5380
+01A2  000220  MOVE.L     -(A0),-(A1)                      | 2320
+01A4  000222  MOVE.L     -(A0),-(A1)                      | 2320
+01A6  000224  MOVE.L     -(A0),-(A1)                      | 2320
+01A8  000226  MOVE.L     -(A0),-(A1)                      | 2320
+01AA  000228  MOVE.L     -(A0),-(A1)                      | 2320
+01AC  00022A  MOVE.L     -(A0),-(A1)                      | 2320
+01AE  00022C  MOVE.L     -(A0),-(A1)                      | 2320
+01B0  00022E  MOVE.L     -(A0),-(A1)                      | 2320
+01B2  000230  MOVE.L     -(A0),-(A1)                      | 2320
+01B4  000232  MOVE.L     -(A0),-(A1)                      | 2320
+01B6  000234  MOVE.L     -(A0),-(A1)                      | 2320
+01B8  000236  MOVE.L     -(A0),-(A1)                      | 2320
+01BA  000238  MOVE.L     -(A0),-(A1)                      | 2320
+01BC  00023A  MOVE.L     -(A0),-(A1)                      | 2320
+01BE  00023C  MOVE.L     -(A0),-(A1)                      | 2320
+01C0  00023E  MOVE.L     -(A0),-(A1)                      | 2320
+01C2  000240  DBF        D0,COPYBLOC+$01A2   ; 00000220   | 51C8 FFDE
+01C6  000244  SUBI.L     #$00010000,D0                    | 0480 0001 0000
+01CC  00024A  BGT.S      COPYBLOC+$01A2      ; 00000220   | 6ED4
+01CE  00024C  BRA.S      COPYBLOC+$01D2      ; 00000250   | 6002
+01D0  00024E  _BlockMove                     ; A02E       | A02E
+01D6  000254  UNLK       A6                               | 4E5E
+01D8  000256  RTD        #$000C                           | 4E74 000C

---------------------------

End of C.S.M.P. Digest
**********************